home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DS-CD ROM 2 1993 August
/
DS CD-ROM 2.Ausgabe (August 1993).iso
/
programm
/
ds0045
/
mbmtexte.exe
/
MBMPAKET.DOC
< prev
next >
Wrap
Text File
|
1992-03-24
|
49KB
|
915 lines
Anleitung zum Maus/Button/Menü Paket für Turbo-Pascal 5.X / 6.X Version 4.1
(C) 1990-1992 BY UWE KUHRING
Kontakt: Uwe Kuhring
Scheidter Str. 281
6602 Dudweiler Saar
Tel.: 06897/768039
Postgiroamt Saarbrücken
BLZ 590 100 66
KNR 522 56 667
Registrierungsgebühr siehe "PREISE.DOC"
****************************************************************************
* ACHTUNG - WICHTIGE ZUSATZINFORMATION *
* Dies ist die SHARE-Version des MBM-Pakets V4.1 *
* Da ich Ihnen hierzu trotzdem die Original-Anleitung der Vollversion zur *
* Durcharbeitung zur Verfügung stellen möchte, werde ich die Abweichungen *
* zur registrierten Version hier kurz aufführen. *
* Der folgende Absatz zum Kopierverbot verliert seine Gültigkeit. *
* In der Share-Version fehlen die 4 Sources-Codes der 4 Units. *
* Die Units wurden folgendermaßen eingeschränkt: *
* Unit MOUSELIB => keine Einschränkung *
* Unit BUTLIB => keine Einschränkung *
* Unit MENULIB => keine Einschränkung *
* Unit WINLIB => keine Einschränkung *
* Die kommerzielle Nutzung dieses Programmpaketes wird erst durch den *
* Vorgang der Registrierung vom Autor freigegeben. Sie können jedoch alle *
* Prozeduren und Units in eigene Programme einbauen und gebührenfrei *
* erproben. Vor dem Verkauf dieser Programme müssen Sie sich registrieren *
* lassen, sonst vertreiben Sie mit Ihren Programmen letztlich Raubkopien! *
****************************************************************************
Zum Urheberrecht: Mit dem Erwerb dieser Vollversion 4.1 des MBM-Pakets
haben Sie ein preisgünstiges Programm zur Gestaltung graphischer
Benutzeroberflächen in Turbo-Pascal erworben. Bitte beachten Sie aber,
daß es sich bei diesem Programm, obwohl es vielleicht der Preis und die
Mitlieferung der Sourcecodes erwarten lassen, nicht um Public-Domain,
sondern um Copyright-geschützte Software handelt. Sie dürfen die Routinen
benutzen, Ihren Erfordernissen anpassen und sie in Ihre Programme einbinden.
Diese Programme können Sie frei verkaufen, ohne daß Lizenzabgaben entstehen.
Untersagt bleibt jedoch die Weitergabe in unkompilierter Form (Source-Codes).
Auch wenn Sie sich entscheiden, bei Ihrem Produkt den Source-Code mit-
zuliefern, dürfen Sie die Source-Codes des MBM-Pakets nicht hinzufügen!
WICHTIG: Als Source-Codes werden hier auch die .TPU Versionen der Libraries
verstanden! Obwohl diese ein Compilat darstellen, sind Sie separat verwend-
bar und bilden so den wesentlichen Teil dieses Programmpaketes. Nur Ihre
.EXE oder .COM Dateien dürfen die Libraries des MBM-Paketes beim Verkauf
enthalten!
Zu den BGI und CHR Dateien: Nach Rücksprache mit Borland habe ich erfahren,
daß es keine Probleme gibt, wenn Sie diese Dateien mit Ihren TP-Programmen
ZUSAMMMEN verkaufen. Diese Programme müssen jedoch einen Hinweis daraufhin
enthalten, daß das Copyright der BGI und CHR Dateien bei Borland liegt.
Diesen Hinweis erteile ich hiermit. Der Verkauf einzelner BGI's und CHR's
ist also NICHT zulässig. Auch kann ich KEINE GARANTIE der Richtigkeit meiner
Behauptung zur lizenskostenfreien Beigabe der BGI und CHR Dateien geben.
Setzten Sie sich im Zweifelsfall besser selbst mit Borland in Verbindung.
P.S.: Ab der Version 3.0 sind nur noch 3 BGI-Dateien als Beigabe enthalten.
Die Verwendung von DRV_LINK.TPU (s.u.) ist eine bessere Lösung, als die
Verwendung der separaten BGI-Dateien.
Haftung: Ich übernehme keinerlei Haftung für Schäden, die durch die
Benutzung des MBM-Paketes in irgendeiner Weise entstehen könnten.
Insbesondere gebe ich keine Garantie der Verwendbarkeit und Funktions-
fähigkeit der beschriebenen Prozeduren, auch wenn dieser Eindruck in der
folgenden Beschreibung der Software entstehen sollte.
Nun zu den Units und Prozeduren des MBM-Paketes:
Unit Prozeduren davon öffentlich uses
mouselib 7 7 graph
butlib 7 5 graph,mouselib
menulib 11 10 graph,mouselib
winlib 9 8 graph,mouselib,butlib
Das Maus/Button/Menü Paket bietet in vier Units insgesamt 30 Prozeduren, die
sowohl den Betrieb der Maus unterstützen, als auch das Implementieren von
Buttons und Menüleisten und Windows auf dem Grafikbildschirm erleichtern.
Die Prozeduren übernehmen die gesamte Handhabung und die Verwaltung der
Buttons, Menüleisten und Menüunterpunkte sowie der Windows.
Systemanforderungen:
1. Eine Grafikkarte aus der Gruppe HGC/CGA/MCGA/EGA/VGA.
2. Eine (M)CGA-Karte muß den Grafikmodus #(5)4 darstellen können (HiRes).
3. Natürlich Turbo-Pascal, und zwar ab Version 5.0
(eventuell sind auch 4.X Versionen verwendbar, dies wurde nicht getestet)
Dringend empfohlen wird ferner:
1. Eine Computermaus, dann aber auch unbedingt mit Treiber.
2. EGA und VGA Karten ermöglichen eine farbige Darstellung.
3. Zur Änderung der MOUSELIB (Source-Code) ist wegen den Assembler-Inline-
Anweisungen eine Turbo-Pascal Version 6.X erforderlich (einz. Ausnahme!)
DIE 4 UNITS SIND AUSSCHLIEßLICH IM GRAFIKMODUS EINSETZBAR!
Die zum Grafikbetrieb erforderlichen .BGI Grafiktreiber gehören jetzt zum
Lieferumfang, beachten Sie jedoch, daß das Copyright dieser Dateien bei
Borland liegt. Das gleiche gilt für die Datei 'LITT.CHR'. Die BGI's und CHR's
sollten im Hauptverzeichnis zu finden sein, ansonsten muß bei der Proze-
dur der Grafikeinstellung (ENTER_DEFAULT_GRAPHMODE in der MOUSELIB)
die Pfadangabe für die .BGI Dateien vorgegeben werden. Zu diesem Zweck muß
beim Funktionsaufruf INITGRAPH der Leerstring gegen die Pfadangabe ersetzt
werden. Eine bessere Alternative hierzu bietet ab der Version 3.0 das Unit
'DRV_LINK.TPU', welches mittels "uses drv_link" in Ihr Programm eingebunden
werden kann. Dann sind stets alle verwendeten Grafiktreiber verfügbar und
obige Probleme entfallen. Ihr Programm wird dadurch allerdings auch einige
KByte länger werden. Ab der Version 3.0 wird die Datei 'LITT.CHR' in keinem
Fall mehr benötigt, wodurch sich der Inhalt der Zusatz-Ordners auf die BGI
Dateien beschränkt.
Es folgt eine Beschreibung der vier Units. Auftretende Fehler werden in den
Variablen MOUSEERROR/BUTTONERROR/MENUERROR/WINDOWERROR entsprechend gemeldet.
Die Fehlercodes finden sich ganz am Ende dieser Beschreibung. Wichtig bleibt
dabei anzumerken, daß sich die Variable MOUSEERROR durchaus auch nach einem
Prozeduraufruf aus der Gruppe BUTLIB/MENULIB/WINLIB verändern kann, da diese
ihrerseits die MOUSELIB benutzen!
Die nun folgende Beschreibung erklärt alle Eigenschaften und Fähigkeiten
des MBM-Paketes in den 1.X Versionen. Für Besitzer einer 2.0 Version folgt
am Ende des Textes eine Beschreibung der zusätzlichen Möglichkeiten.
Darauf folgen spezielle Hinweise zur Version ab 3.0 und höher.
In den "*" Kommentaren werden wichtige Änderungen der Versionen ab 3.0 jedoch
schon vorweggenommen.
******************************************************************************
******************************************************************************
Unit MOUSELIB
-------------
Folgende Prozeduren stehen zur Verfügung:
***************************
* ENTER_DEFAULT_GRAPHMODE *
***************************
Eigentlich hat diese Prozedur nichts in der MOUSELIB zu suchen - diese
Library bot sich allerdings an, da sie von allen anderen Libraries benutzt
wird. So steht die Prozedur überall zur Verfügung.
Sie schaltet den Rechner in den Grafikbetrieb und wählt dabei einen für
Menüs und Buttons günstigen Grafikmodus aus. Danach wird noch das
Vorhandensein einer Maus überprüft. Sollte diese fehlen oder kein brauch-
barer Grafikmodus zu finden sein, wird das GESAMTE PROGRAMM mit einer
entsprechenden Meldung ABGEBROCHEN.
Sie können natürlich auch eine eigene Prozedur verwenden, wenn z.B. ein
Programmabbruch in diesen Fällen nicht erwünscht ist, oder Sie einen
ganz bestimmten Grafikmodus auswählen wollen!
* Versionen ab 3.0 erlauben auch den Betrieb ohne Maus. Das Programm wird
in diesem Fall natürlich nicht abgebrochen.
**************************************
* MOUSECHECK (var BUTTONS : integer) *
**************************************
Überprüft zunächst, ob ein Grafikmodus ausgewählt wurde. Nur im Grafik-
betrieb macht die Installation von Buttons und ihre Mausbedienung Sinn
(falls man diesen komischen Blockcursor im Textmodus nicht als Mauszeiger
huldigt, was mir eher schwer fällt).
Ist dies nicht der Fall, enthält die Variable MOUSEERROR die Zuweisung -1.
Ansonsten wird noch geprüft, ob überhaupt ein Maustreiber zur Verfügung
steht. Falls nicht, wird MOUSEERROR -2 und die Bearbeitung abgebrochen.
Wird hingegen ein Treiber gefunden, wird in BUTTONS die Anzahl der
Knöpfe der installierten Maus und in mouseerror 0 übergeben. Im Fehlerfall
enthält BUTTONS den gleichen Wert wie MOUSEERROR. Diese Prozedur übernimmt
auch die Definition des Mauszeigers. Die dazu benötigten 32 Words werden
in einem unübersehbaren Feld in der Prozedur MOUSECHECK definiert. Sie
können die Werte ändern, um sich einen eigenen Zeiger zu definieren.
* Wie bereits erwähnt, bricht das Programm ab der Version 3.0 NICHT ab,
wenn keine Maus gefunden wurde. In diesem Fall enthält die globale Variable
MOUSECHECKED den Wert 99, im anderen Fall die Anzahl der Knöpfe der Maus.
***********
* MOUSEON *
***********
Schaltet die Maus einmal ein. Wurde sie mehrfach ausgeschaltet, muß sie
entsprechend oft wieder eingeschaltet werden, bis sie sichtbar wird.
* Ist keine Maus vorhanden macht dieser Befehl - nichts.
************
* MOUSEOFF *
************
Schaltet die Maus einmal aus. Mehrmaliges Ausschalten wird gespeichert,
was den Betrieb in Prozeduren wesentlich erleichtert.
* Dieser Befehl (wie auch die folgenden) macht nichts, wenn keine Maus
gefunden wurde.
***********************************
* MOUSESTAT (var X,Y,B : integer) *
***********************************
Übergibt in X die aktuelle X-Koordinate der Maus und in Y die aktuelle
Y-Koordinate. B enthält einen Bitvektor, der sich aus den auf der Maus
gedrückten Tasten zusammensetzt:
linke Taste : bit 0 gedrückt = 1 ungedrückt = 0
rechte Taste : bit 1 gedrückt = 2 ungedrückt = 0
mittlere Taste : bit 2 gedrückt = 4 ungedrückt = 0
Die mittlere Taste steht nicht bei jedem System zur Verfügung.
MOUSEERROR enthält die üblichen Fehlercodes oder 0.
* Ist keine Maus vorhanden, enthält die Variable B stets 0 und in X und Y
sind die Werte von GETMAXX und GETMAXY zu finden.
****************************
* MOUSESET (X,Y : integer) *
****************************
Dient zum Setzen der Maus an eine bestimmte Position auf dem Grafikbild-
schirm. Dabei müssen sich X und Y in den durch GETMAXX und GETMAXY
vorgegebenen Grenzen befinden. Tun sie das nicht, wird die Maus nicht
bewegt und MOUSERROR erhält die Zuweisung -3. Zusätzlich zu diesem
Fehlercode können die anderen zwei Maus-Fehlercodes auftreten.
***************************************
* MOUSEWINDOW (X1,Y1,X2,Y2 : integer) *
***************************************
Dient der Definition eines Fensters in das die Maus "eingesperrt" wird.
X1,Y1 definieren die linke obere Ecke und X2,Y2 die rechte untere Ecke
dieses Fensters. Dabei muß gelten:
0 <= X1(Y1) <= X2(Y2) <= GETMAXX(Y)
Ansonsten wird MOUSEERROR -3. Die Fehlercode -1 und -2 können auch auftreten.
MOUSEWINDOW (0,0,GETMAXX,GETMAXY) setzt das gesamte Grafik-Fenster.
Das waren die Maus-Prozeduren. Mittels "uses mouselib" kann die Maus auch
ohne die Button/Menu-Prozeduren verwendet werden, was umgekehrt nicht
möglich ist.
*******************************************************************************
*******************************************************************************
Unit BUTLIB
-----------
Folgende Prozeduren stehen zur Verfügung:
*************************************************************
* DEFBUTTON (P,B,X,Y : integer ; T : string ; S : boolean; *
* C : char ; U : byte) *
*************************************************************
Definiert die Position des Button B durch die Angabe der Koordinaten X und Y.
B muß zwischen 1 und MAXBUTTONS liegen (default=64), während X und Y in den
durch GETMAXX und GETMAXY definierten Grenzen liegen müssen. P definiert die
Button-Ebene, der der Button angehören soll. In der vorliegenden Version
stehen dazu 4 verschieden Ebenen (1..4) zur Verfügung.
In T wird der in den Button einzutragende Text übergeben und wenn S wahr ist,
wird der Button später schattiert gezeichnet werden. In der Variablen C wird
ein zum Mausbetrieb alternativer Buchstabe angegeben. Später kann dieser
Button über die Tastenkombination <ALT> <BUCHSTABE> angeklickt werden.
Zulässig für C sind die Großbuchstaben 'A' bis 'Z' sowie die Zahlen '0' bis
'9'. Soll diese Option nicht verwendet werden, muß C das Leerzeichen ' '
enthalten. U definiert schließlich die Nummer des zu unterstreichenden
Buchstabens im Textstring. So können Sie dem Benutzer mitteilen, welche
<ALT> <?> Kombination einen beliebigen Button anklickt. Lautet Ihr Button-
text z.B. 'Exit' und ist C='X', kann der Exit-Button mit ALT X angeklickt
werden. Dies solltem Sie dem Benutzer mitteilen, indem Sie das X unter-
strichen darstellen (U=2). Wenn U=0 ist, wird kein Buchstabe unterstrichen.
Wichtig: Der Button wird durch seine Definition noch nicht gezeichnet.
Wichtig: BUTTONERROR -3 (ungültige Koordinaten) kann auch dann auftreten,
wenn X und Y zulässige Werte enthalten. In diesem Fall würde der
Text des Buttons den rechten Rand des Bildschirms überschreiten!
Wichtig: Vergeben Sie auf einer Ebene nicht zweimal die gleiche <ALT> <?>
Kombination zur Button-Aktivierung! Es würde stets nur der erste
Button angeklickt werden können.
********************************
* DEFBUTTONPLANE (N : integer) *
********************************
Aktiviert eine Ebene des Button-Handlers. Alle definierten Buttons dieser
Ebene werden nun gezeichnet. Der Bildschirm wird vorher NICHT automatisch
gelöscht. Die verwendete Zeichenfarbe ist die eingestellte Zeichenfarbe.
Alle Rückgaben der weiteren Prozeduren beziehen sich auf diese Ebene.
************************************************************************
* PRESSEDBUTTON (var BUTTON,MOUSEBUT : integer ; var SCAN_CHAR : char) *
************************************************************************
Liefert Informationen über die Position des Mauszeigers in der durch
DEFBUTTONPLANE definierten Ebene. Enthält BUTTON 0, so befindet sich der
Mauszeiger über keinem Button der definierten Ebene. Ansonsten enthält
BUTTON die Nummer des Buttons, über dem der Mauszeiger "schwebt".
MOUSEBUT erteilt darüber hinaus Information darüber, welche Maustasten
zur Zeit gedrückt werden. Das Format ist das bei MOUSESTAT beschriebene.
Soll auch die Tastaturbedienung des Buttonhändlers unterstützt werden,
so muß in SCAN_CHAR das nach dem NUL-Zeichen gelesene Zeichen an die Routine
übergeben werden. (Siehe auch MB_DEMO und "ERWEITERTE TASTATURCODES" im
Turbo-Pascal Benutzerhandbuch.)
Hat sich ein Button für dieses Zeichen in SCAN_CHAR für zuständig erklärt,
wird BUTTON entsprechend und MOUSEBUT auf 1 gesetzt. SCAN_CHAR wird dann
das Zeichen CHR(255) zugeschrieben, um die Abarbeitung zu kennzeichnen.
******************************
* REVERTBUTTON (N : Integer) *
******************************
Invertiert die Farbe des Buttons N in der aktuellen Ebene. Ein erneuter
Aufruf dieser Funktion stellt den ursprünglichen Zustand wieder her.
*****************************************************************
* DEFTEXTBUTTON (P,B,X,Y : integer ; T : string ; S : boolean; *
* C : char ; U : byte) *
*****************************************************************
Ist der Prozedur DEFBUTTON sehr ähnlich und ruft diese auch auf.
Während DEFBUTTON jede Position auf dem Grafikbildschirm für die Instal-
lation eines Buttons zuläßt, erzeugt die DEFTEXTBUTTON Prozedur eine
Art GOTOXY mit anschließendem WRITE.
Der Vorteil der ersten Funktion liegt in Ihrer beliebigen Anordnungs-
möglichkeit der Buttons, ihr Nachteil in der schlechten Berechenbarkeit
sinnvoller Positionen und vor allem die Abhängigkeit von der verwendeten
Grafikkarte. Die zweite Prozedur ermöglicht hingegen eine "normalisierte"
Ausgabe von Buttons auf dem Bildschirm. Allerdings wird ein Zeichensatz
benötigt, der ein Bildschirmformat von 80x25 Zeichen ermöglicht. Dafür wird
die Abhängigkeit von verwendeten Grafikkarten beseitigt. Entsprechend oberer
Norm muß bei DEFTEXTBUTTON der Wert von Y zwischen 1 und 23 liegen
(entsprechend den Zeilenzahlen 0..24) und der Wert von X zwischen 1 und 78
(entsprechend den Spaltenzahlen 0..79). Die ersten und letzten Zeilen
(Spalten) können wegen der Button-Umrandung nicht genutzt werden.
Des weiteren darf der Wert von X nicht so groß sein, daß mit dem Text das
Zeilenende erreicht würde. Zwischen zwei Buttons sollte eine Leerzeile
liegen, womit in eine Spalte maximal 12 Buttons passen. Zwar ist bei EGA/VGA
Karten eine Anornung in jeder Zeile möglich, dies kann jedoch bei anderen
Karten zu Überlappungen führen.
Noch eine wichtige Anmerkung zum Zeichensatz: Die Wahl eines passenden
Zeichensatzes kann u.U. recht mühsam sein. Der Aufruf der Prozedur
ENTER_DEFAULT_GRAPHMODE, der in den Demoprogrammen obligatorisch ist, sollte
stets zum Starten des Grafikmodus eingesetzt werden.
Das waren alle 5 (öffentlichen) Prozeduren der BUTLIB.
***********************
* CLEAR_EXIST_BUTTONS *
***********************
Zusätzlich existiert in der BUTLIB noch diese Prozedur, die beim Start der
BUTLIB dafür sorgt, daß alle Buttons zunächst als unbelegt gelten. Ein
späterer Aufruf würde alle Buttons in einem Programm löschen, was keinen
Sinn macht. Für verschiedene Menüs stehen schließlich verschiedene Ebenen
zur Verfügung, wodurch eine Neudefinition einer Ebene unnötig wird.
*******************
* INIT_SCAN_ARRAY *
*******************
Auch diese Prozedur wird beim ersten Start des Units einmal aufgerufen. Sie
stellt ein Link zwischen SCAN-CODES und ASCII-CODES her und ist durchaus
erweiterbar.
Sollten 4 Ebenen oder 64 Buttons pro Ebene nicht ausreichen, können diese
Werte im Interface-Teil der BUTLIB erhöht werden. Dazu müssen nur die
Konstanten MAXPLANES und MAXBUTTONS andere Zuweisungen erhalten. Die
Größe der Werte von MAXPLANES und MAXBUTTONS wird nur durch den verfügbaren
Speicher begrenzt.
*****************************************************************************
*****************************************************************************
Unit MENULIB
------------
*************************
* CLR_ALL_MENUREGISTERS *
*************************
Kennzeichnet alle Menüeintrage als unbelegt, also frei. Dies ist nötig,
damit beim ersten MENUON nicht allerlei Unsinn in den Menüs erscheint.
Die Prozedur kann jedoch auch problemlos zum endgültigen Löschen der
gesamten Menüleiste benutzt werden. (Den Erstaufruf übernimmt das Unit
selbst, ein CLR_ALL_MENUREGISTERS Befehl im Programm ist nicht nötig)
*******************************
* CLR (X1,Y1,X2,Y2 : integer) *
*******************************
Löscht einen rechteckigen Ausschnitt des Grafikbildschirmes. Ähnlich wie
bei CLEARDEVICE wird dieser Teil mit der Hintergrungfarbe überschrieben.
x1 und y1 definieren die linke obere und x2 sowie y2 die rechte untere
Ecke dieses Ausschnittes.
Diese Prozedur wird von den Prozeduren der Menügrafikdarstellung benutzt,
kann jedoch auch von außen zum Löschen von Bildschirmteilen genutzt werden.
************************************************
* MENUREGISTER (X,Y : integer ; NAME : string) *
************************************************
Definiert den Namen des Eintrages in der Spalte X und der Zeile Y. Der
später dort erscheinende Text wird in NAME übergeben.
In der jetzigen Version werden maximal 7 Hauptmenüspalten zugelassen.
Dementsprechend muß X zwischen 1 und 7 liegen, womit die X-te Spalte
angesprochen wird. Y definiert hingegen die Position in der Spalte X, also
die gewünschte Zeile. Es werden maximal 12 Einträge pro Hauptmenüpunkt
zugelassen. So muß also Y zwischen 0 und 12 liegen. Mit 0 wird der Menü-
oberbegriff (der Eintrag in der Hauptmenüzeile) definiert, liegt Y
zwischen 1 und 12 dann die entsprechende Zeile im Menü selbst.
Sowohl Hauptmenüpunkte als auch Unterpunkte können übersprungen werden, so
kann z.B. der Hauptmenüpunkt Nr.7 als erster definiert werden.
Ein Hauptmenüeintrag darf bis maximal 8 Zeichen, ein Untermenüeintrag jedoch
bis zu 16 Zeichen lang sein. Wird in NAME ein Nullstring übergeben, wird
der entsprechende Eintrag aus dem Menü gelöscht.
**********
* MENUON *
**********
Stellt das bis dato mittels MENUREGISTER definierte Menü auf dem Grafik-
bildschirm dar. Dabei werden die oberen 4% des Bildschirmes ausgenutzt.
Darunter liegende Informationen gehen verloren. Es werden (logischerweise)
nur Hauptmenüpunkte dargestellt. So nützt es wenig, wenn alle 12 Untermenü-
einträge eines Menüs definiert wurden, aber noch kein Hauptmenüeintrag.
Dieses Menü erscheint nicht und wird später bei 'vernünftiger' Program-
mierung unzugänglich bleiben.
ACHTUNG: Sollte es aus irgendeinem Grund nötig sein, das Menü während
seines Betriebes zu verändern, sollte zunächst MENUOFF mit
anschließendem MENUON genutzt werden, um den gewünschten
Effekt der Aktualisierung zu erreichen.
***********
* MENUOFF *
***********
Schaltete das aktuelle Menü vollständig ab. Die Menüleiste wird gelöscht
und die meisten Menüprozeduren verweigern Ihren Dienst. Diese Aufrufe
führen dann zu MENUERROR=-10 (Menü ist nicht eingeschaltet).
******************************
* MENUMARK (X,Y,Z : integer) *
******************************
Zusätzlich zum Menünamen kann im Menü eine Markierung des entsprechenden
Eintrages erscheinen. Mit X und Y wird der gewünschte Eintrag, wie unter
MENUREGISTER beschrieben, angesprochen. Z enthält eine Zahl zwischen 0
und 2, welche die gewünschte Markierungsart festlegt. 0 bedeutet dabei keine
Markierung bzw. Markierung löschen, falls des Menü gerade heruntergeklappt
ist. Diese Markierung (also keine Markierung) wird auch jedem neu definier-
tem Eintrag als erstes zugewiesen. Ist Z=1 dann wird der Menüeintrag als
unzugänglich gekennzeichnet. Dann erscheint links vom Menüeintrag das Symbol
der leeren Menge, um diesen Zustand zu kennzeichnen. Ein solcher Eintrag ist
nun tatsächlich aus dem Menü verschwunden. Zwar wird er beim Herunterklappen
des Menüs noch angezeigt, aber die Prozedur MENUSTAT behandelt diesen
Eintrag wie einen nicht definierten. Dieses Verhalten ermöglicht ein
äußerst simples und effektives Verfahren, um von einem Programm eine Demo-
version zu erzeugen: Es braucht nur ein wichtiger Menüeintrag nach seiner
Definition als unzugänglich gezeichnet werden, schon ist es dem Anwender
unmöglich, diesen Punkt aufzurufen. Dazu sollte noch aus dem entsprechenden
Programmteil eine wichtige Zeile gelöscht werden. Schon diese zwei Aktionen
liefern sowohl Betriebssicherheit, als auch relativ guten Schutz vor Hackern.
Mit Z=2 wird ein Menüeintrag als aktiviert gekennzeichnet (mit einem Haken).
Im Gegensatz zur vorherigen Markierung hat diese keinerlei Einfluß auf
weitere Prozeduren und dient nur der Übersichtlichkeit.
**************************
* MENUPULL (N : integer) *
**************************
Klappt das mit N definierte Menü herunter. N muß zwischen 1 und 7 liegen
und damit ein Menü beschreiben, welches mindestens 1 Eintrag enthalten
muß. Ein nur aus seinem Namen bestehendes Menü kann nicht heruntergeklappt
werden. Alle unter dem Menükasten liegenden Bildschirminformationen (das
sind bis zu 16% des Bildschirmes) werden gesichert. Es werden alle
definierten Einträge und Markierungen dieses Menüs sichtbar.
Da immer nur ein Menü zur gleichen Zeit heruntergeklappt sein darf, führt
diese Prozedur in dem Fall, daß bereits ein Menü heruntergeklappt ist,
zunächst ein MENUPUSH aus und klappt anschließend das gewünschte Menü
herunter.
************
* MENUPUSH *
************
Da stets höchstens ein Menü heruntergeklappt ist, ist eine weitere Angabe
von Parametern für diese Prozedur unnötig.
Die Prozedur klappt das momentan heruntergeklappte Menü wieder hoch. Die
vor dem Herunterklappen des Menüs gesicherten Bildschirminformationen werden
restauriert, womit der Bildschirm wieder so aussieht, wie vor dem Aufruf von
MENUPULL. (Es sei denn, man verändert während ein Menü heruntergeklappt ist,
den Bildschirm, was man tunlichst unterlassen sollte!)
****************************************************************
* MENUSTAT (var X,Y,MOUSEBUT : integer ; var SCAN_CHAR : char) *
****************************************************************
Liefert Informationen über die Positionen des Mauszeigers (der sichtbar sein
sollte => MOUSEON benutzen) bezüglich des aktuell dargestellten Menüs.
MOUSEBUT ist absolut funktionsgleich mit MOUSEBUT bei der MOUSELIB-Prozedur
MOUSESTAT. SCAN_CHAR wird wie bei der PRESSED_BUTTON Routine in der
BUTLIB zur Tastaturbedienung der Menüleiste benutzt. Sehen Sie sich bitte
die Anleitung dieser BUTLIB-Prozedur nocheinmal an. Sie sollten aber auch
unbedingt das kurze Kapitel über die erweiterten Tastaturcodes in den TP-
Handbüchern lesen. Auch die Demo-Programme MB_DEMO und MENUDEMO zeigen,
wie SCAN_CHAR verwendet werden kann.
Nach dem Aufruf:
Y und X geben die Zeile und Spalte wieder, über der sich der Mauszeiger
zur Zeit befindet. Da nur die Spalten 1 bis 7 definiert sind, bedeutet eine
0 in X nach dem Aufruf dieser Prozedur, das sich die Maus über keinem
anwählbaren Eintrag befindet. Dabei ist auch stets Y=0, woraus man leicht
folgern kann: Dann und nur dann wenn (X+Y)>0 steht der Mauszeiger über einem
anwählbaren Eintrag. Da man jedoch aus X=0 nur folgern kann, daß die Maus
über keinem ANWÄHLBAREN Eintrag steht, kann man ein heruntergeklapptes
Menü deshalb nicht einfach wieder hochklappen. Der Mauszeiger könnte auf
einem leeren oder unzugänglichen Eintrag stehen und das Menü würde plötzlich
verschwinden. In diesem Fall hilft die nach jedem Aufruf von MENUSTAT
aktualisierte Variable MENULEFT, die immer dann wahr (true) ist, wenn sich
der Mauszeiger über keinem Menükasten oder über einem nicht zum aktuell
heruntergeklappten Menükasten gehörenden Menüpunkt befindet. In diesem
Zusammenhang sollen einmal alle weiteren Variablen, die zusätzliche
wichtige Informationen liefern können beschrieben werden:
1. MENUERROR : Fehlervariable, siehe Ende dieser Beschreibung.
2. MENULEFT : Ist im obigen Text gerade beschrieben worden.
3. MENUPULLED : Enthält die Nummer des gerade heruntergeklappten Menüs
oder 0, wenn kein Menü heruntergeklappt ist.
4. REVERTED : Enthält die Nummer des gerade invertierten Menüuntereintrages
oder 0, falls kein Untereintrag invertiert ist.
5. MENUVIEW : Ist wahr (true) wenn MENUON als letztes aufgerufen wurde,
bzw. unwahr (false) nach MENUOFF oder dem Start des Units.
6. KEY_MODE : Ist wahr, wenn das aktuell heruntergeklappte Menu von der
Tastatur aktiviert wurde und die Maus das Menü noch nicht
übernommen hat.
*********************************
* MENUREVERT (N,MODE : integer) *
*********************************
Invertiert (kennzeichnet mit invertierten Farben) den Untereintrag mit der
Nummer N im aktuell heruntergeklappten Menü.
Dazu muß sowohl ein Menü heruntergeklappt sein, als auch der gewünschte
Eintrag existieren, d.h. definiert sein. Da kein Haupteintrag invertiert
werden kann, muß N zwischen 1 und 12 liegen.
Es kann immer nur höchstens ein Eintrag invertiert sein. Wird mit N ein
anderer als bereits im Menü invertierter Eintrag angegeben, so wird zunächst
der alte Eintrag wieder auf 'normale' Färbung gebracht.
Ist MODE=1 dann wird der Eintrag wie beschrieben durch Invertierung von den
anderen Einträgen abgehoben.
Ist MODE hingegen =0 wird der Eintrag wieder auf 'normale' Färbung gebracht.
Während es bei MODE=1 wichtig ist, welcher Eintrag mit N gekennzeichet ist,
ist bei MODE=0 diese Angabe durch Eindeutigkeit eigentlich unnötig. Trotzdem
muß N den formalen Bedingungen genügen, ansonsten ist sein Inhalt nicht
von Bedeutung. MENUREVERT(1,0) stellt also in jedem Fall den Menükasten
wieder ohne Invertierungen dar.
Das war die Beschreibung der 10 (öffentlichen) MENULIB-Prozeduren.
*************************
* REVERT (N : integer); *
*************************
Diese zusätzliche nicht-öffentliche Prozedur übernimmt den eigentlichen
Invertiervorgang. Da diese Funktion weder Bereichsprüfungen vornimmt,
noch irgendeinen weitergehenden Sinn hat, ist ihre Unterbringung im
Implementationsteil am sinnvollsten.
*******************************************************************************
*******************************************************************************
Verbesserungen in der Version 2.0
---------------------------------
Diese Version wurde in zweierlei Hinsicht erweitert. Zunächst können nun
16 Untermenüs verwaltet werden, anstatt nur maximal 12 Untermenüs.
Die ganz wesentliche Erweiterung ist jedoch die Möglichkeit, Buttons und
Menüs jetzt farbig zu gestalten. Die Programme des MBM-Paketes erkennen
selbstständig die Grafik-Karte und stellen die Menüs und Buttons bei
HGC, CGA und MCGA schwarz/weiß und bei EGA/VGA-Karten farbig dar.
Dabei kann für jedes Untermenü bzw. jeden Button eine beliebige von 16
Farben ausgewählt werden.
Falls Sie nun befürchten, Ihre Programme umschreiben zu müssen, um Farbe
in die Menüs zu bekommen, kann ich Sie beruhigen. Es ist nämlich nicht
notwendig die Programme umzuschreiben; nur wenn Sie eigene Farben setzen
wollen, ist eine ERGÄNZUNG Ihrer Programme um eine oder zwei Prozeduren
erforderlich, die anderen Prozeduren bleiben unverändert!
Die Vorgehensweise:
Wenn Sie die ENTER_DEFAULT_GRAPHMODE Prozedur der Mouselib verwenden, sind
Ihre Menüs und Buttons bei EGA- und VGA-Karten automatisch farbig. Sollten
Sie jedoch mit einer eigenen Routine den Grafik-Modus einschalten, müssen
Sie die Variable VGA_EGA_CARD unbedingt selbst setzen. Sollte Ihr System
über eine EGA- oder VGA-Karte verfügen, ist dazu die Anweisung
VGA_EGA_CARD := true;
ansonsten jedoch die Anweisung
VGA_EGA_CARD := false;
in die ersten Anweisungen Ihres Programmes (vor Menü- und Button-Aufrufen)
einzufügen. Wird diese Zuweisung fortgelassen, ist der Inhalt der Variablen
VGA_EGA_CARD nicht definiert und das MBM-Paket arbeitet fehlerhaft!
Setzen Sie hingegen VGA_EGA_CARD grundsätzlich auf FALSE, dann arbeitet
die Version 2.0 stets so, wie Ihre 1.X Vorgänger, also farblos.
Benutzer der ENTER_DEFAULT_GRAPHMODE Prozedur können die Variable jedoch,
wie bereits erwähnt, getrost vergessen.
An den Parametern und Deklarationen der Prozeduren der drei Units ändert
sich nichts. Die Farbe von Menüs und Buttons wird vielmehr über 2 Felder
definiert. Da die Felder öffentlich sind, können sie Sie aus Ihrem Programm
heraus manipulieren.
Die Farbe von Menüs wird in dem Feld COLOR_ARRAY [A,B] definiert.
A darf zwischen 0 und 7 liegen und bezeichnet im Falle von A=0 das Haupt-
menü und im Falle von A=1 bis A=7 das entsprechende Untermenü.
Mit B legen Sie fest, für welchen Teil der Anzeige Sie die Farbe definieren
wollen:
B=0 => Die Farbe für den Menühintergrund
B=1 => Die Farbe für den Menürahmen
B=2 => Die Farbe für die Menütexteinträge
B=3 => Die Farbe für die Menümarkierungen
Mit der Anweisung "COLOR_ARRAY [0,0] := 4 ;" legen Sie die Hintergrundfarbe
des Haupmenüs auf Rot fest und mit "COLOR_ARRAY [5,3] := 14 ;" erreichen
Sie, daß alle Markierungen des 5. Untermenüs in Gelb dargestellt werden.
(Siehe auch TP-Handbuch unter Graph: Frabkonstanten).
Die Farbe der Buttons wird ganz ähnlich gehandhabt, nur daß hier jeder
Button seine eigene Farbe bekommen kann.
Bei den Buttons ist es das Feld BUTTON_COLORS, welches die Farbinformation
der Buttons beinhaltet. Eine mögliche Anweisung wäre:
BUTTON_COLORS [A,B,C] := MEINE_FARBE ;
wobei A die Buttonebene beschreibt und somit zwischen 1 und 4 liegen darf.
B definiert den angesprochenen Button der Ebene A und C legt wieder fest,
für welchen Teil des Buttons die Farbe gesetzt wird:
C=0 => Die Farbe des Button-Hintergrundes
C=1 => Die Farbe der Button-Umrahmung
C=2 => Die Farbe des Button-Textes
Beispiele:
BUTTON_COLORS [1,1,0] := 6 ;
BUTTON_COLORS [1,1,1] := 11 ;
BUTTON_COLORS [1,1,2] := 7 ;
Diese Kombination legt den Hintergrund des Buttons 1 der Ebene 1 auf braun,
den Rahmen des Buttons auf helltürkis und die Textfarbe auf hellgrau fest.
Es ist natürlich wichtig, daß Sie alle Farb-Definitionen der Buttons und
Menüs vornehmen, BEVOR Sie sie anzeigen lassen, sonst wird immer die
Standard-Farbe verwendet werden.
Sollten noch immer Unklarheiten bestehen: Experimentieren Sie etwas mit den
Programmen MB_DEMO.PAS und MENUDEMO.PAS und alles sollte klar werden.
*******************************************************************************
*******************************************************************************
Verbesserungen in der Version 3.0
---------------------------------
Die völlig neu überarbeitete Version 3.0 enthält entscheidende Änderungen
gegenüber ihren Vorgängern:
1. Der unschöne Vektorzeichensatz bei HGC/CGA/MCGA wird nicht mehr verwendet.
Sollten bei diesen Karten eventuell einige Zeichen (ß,ä,ü,ö usw.) fehlen,
so ist "GRAFTABL" (DOS-Befehl) vor dem (ersten) Programmstart von DOS aus
aufzurufen. Noch besser ist der Einbau von "GRAFTABL" in Ihre AUTOEXEC.BAT
Datei.
2. Das Unit "DRV_LINK.TPU" ermöglicht das Einbinden der 3 benötigten Grafik-
treiber (BGI-Dateien) in jedes Turbo-Pascal Programm.
3. Eine Maus ist nicht erforderlich (aber wünschenswert), denn die Buttons und
Menüs können auch über die Tastatur gesteuert werden. Somit erfolgt bei
fehlender Maus kein Programmabbruch mehr.
4. Die Prozeduren der Mouselib nutzen die Möglichkeiten von Turbo-Pascal 6.0
zum direkten Einbinden von Assembler-Quell-Code.
5. Buttons sind nicht nur mit der Maus, sondern auch über <ALT> <?> Tastatur-
kommandos zu aktivieren. Das Verfahren ist optional.
6. Die Daten des Buttonhandlers werden nun nicht mehr im Datensegment,
sondern über Pointer dynamisch auf dem Heap verwaltet. Somit entfällt der
unerfreuliche Zugriff des Buttonhandlers auf ca. 1/3 des Datenspeichers.
7. Hauptmenüs können über die Tastenkombination <ALT> <Fn> heruntergeklappt
werden, wobei n zwischen 1 und 8 liegen muß und den gewünschten Hautein-
trag angibt. Ist n=8 wird jedes Menü wieder eingeklappt.
Ist ein Menü heruntergeklappt, kann mit den Cursortasten ein Eintrag
ausgewählt und mit Return auch aktiviert werden.
8. Auch bei der Menübedienung hat die Maus Vorrang, d.h. man kann mit der
Maus ein von der Tastatur aktiviertes Menü übernehmen.
9. Ein viertes Unit (WINLIB) ermöglicht das Abwickeln von Text-Ein/Ausgaben
in Fenstern, woduch in Verbindung mit Buttons und Menüs keinerlei direkte
Ausgabe von Texten auf dem Grafikbildschirm erforderlich ist. Dieser steht
somit für Grafik (oder auch nur Hintergrund) zur Verfügung.
Verbesserungen in der Version 3.1
---------------------------------
Einige Bugs (bzw. Unschönheiten) der Version 3.0 konnten beseitigt werden:
1. "WPRINT" (Winlib) mit einem leeren String funktioniert jetzt ordentlich,
was bedeutet, daß nichts geschieht. Der Bildschirm wird in diesem Fall
also nicht mehr mit einem wilden Muster gefüllt.
2. Wird "PRESSEDBUTTON" (Butlib) ohne Maustreiber und nur mit Tastatur-
bedienung aufgerufen, wird nun "MOUSEBUT" auch auf Null gesetzt, wenn
kein <RETURN> gedrückt wurde und nicht einfach der alte Wert zurück-
geliefert.
Das waren die Bugs - es folgen die beseitigten Unschönheiten:
1. Auch bei diesem Shareware-Programm kann man jetzt (wie bei meinen anderen
Programmen) mit <ESC> ein Menü wieder hochklappen.
2. Die graue "Schriftunterlage" der Window-Überschriften wird im dem Fall,
daß sie mit seitlichen Überständen zu lang würde, auf die Schriftgröße
angepaßt und nicht einfach weggelassen.
3. Wird als Window-Überschrift ein Leerstring angegeben, wird jetzt nicht
mehr ein kleines Stück "Schriftunterlage" in der oberen Leiste angezeigt,
sondern die Umrandung des Fensters durchgehend gestaltet.
Dazu kommen ein paar kleine Erweiterungen
1. Durch Setzen der Winlib-Variablen SCREEN_SAVE auf FALSE (Default = TRUE)
können bel. große Fenster geöffnet werden. Das funktioniert deshalb, weil
der Hintergrund dann NICHT gesichert wird. Daraus folgt aber auch, daß
nach CLOSE_WINDOW der Bildschirm nicht wieder restauriert wird. Auf dem
Bilschirm passiert sogar offensichtlich überhaupt nichts. Trotzdem muß
CLOSE_WINDOW aufgerufen werden, damit die Window-Handle-Nummer wieder
freigegeben werden kann. Diese Möglichkeit ist von Nutzen, wenn für ein
Programm ein großes Fenster im Hintergrund geöffnet wird, welches bis zum
Programmende nicht wieder geschlossen wird. Vergessen Sie nicht, die
Variable SCREEN_SAVE nach dem Öffnen dieses Windows wieder auf TRUE zu
setzen, damit sich die weiteren Fenster "normal" verhalten.
2. Das Programm MENUDEMO.EXE wurde leicht ergänzt.
3. Das neue Programm WINDEMO.EXE demonstriert ein wenig die Möglichkeiten
der Winlib, allerdings mit SCREEN_SAVE = FALSE. Es wäre allerdings auch
ziemlich unmöglich, mehrere tausend Window-Inhalte von Grafik-Windows
zu speichern, ohne eine ganze Festplatte damit vollzupacken.
Zur Version 3.2
---------------
Da beim aktuell verwendeten Zeichensatz bei HGC-Karten 90 Zeichen in eine
Zeile passen, wurde in der Winlib auch die Möglichkeit eröffnet, Fenster mit
einer Breite bis zu 88 Textzeichen zu öffnen.
Die Text-Ausgabe in Windows erfolgt bei HGC-Karten dieser Option angepasst.
Für alle anderen Grafik-Karten ändert sich jedoch nichts !
Zur Version 3.3
---------------
Man kann jetzt Fenster, die sich horizontal über den ganzen Bildschirm
erstrecken, auch wieder schließen. Open_Window, Clear_Window und WPrint
arbeiten ca. 3 mal so schnell wie in den vorherigen Versionen. Wird für
den Rahmen die gleiche Farbe wie für den Fenster-Hintergrund angegeben,
wird dieser nicht durch ein Muster hervorgehoben.
Die Schattenfarbe der Buttons ist ab jetzt genau wie bei allen anderen
Objekten schwarz. Geöffnete Menüs erzeugen ab dieser Version ebenfalls einen
Schatten. Nach den Buttons wird nun auch der Speicherbedarf der Menulib
teilweise dynamisch verwaltet. Dadurch gibt es aber auch einen neuen
möglichen Fehlercode: -15 für "zuwenig Speicher".
*******************************************************************************
*******************************************************************************
Die WINLIB der Versionen 3.X
----------------------------
**************************************************
* OPEN_WINDOW (X0,Y0,X1,Y1,C,B: integer ; *
* var N : integer ; TITLE : string) *
**************************************************
Öffnet ein Fenster mit der linken oberen Ecke in X0 und Y0 und der rechten
unteren Ecke in X1 und Y1. Diese Koordinaten beschreiben Textpositionen und
sind nicht etwa pixelorientiert. Außerdem definieren die Koordinaten die
beschreibbare Fläche - die Umrandung ist jeweils 1 Zeichen breiter. Die
X-Koordinaten müssen zw. 1 und 78 und die Y-Koordinaten zw. 1 und 23 liegen.
C definiert die Rahmenfarbe und B die Farbe des Fensterhintergrundes.
Die Prozedur liefert in N eine Nummer zurück, über die das Fenster in Zukunft
angesprochen werden kann. Mit TITLE wird definiert, welche Überschrift das
Fenster tragen soll.
Es können maximal 10 Fenster gleichzeitig geöffnet sein. Die Fenster müssen
in umgekehrter Öffnungsfolge wieder geschlossen werden, außer wenn jede
Form von Fenster-Überlappung ausgeschlossen werden kann.
ACHTUNG: Der unter einem Fenster liegende Hintergrund darf maximal 65000
Bytes Speicher zur Sicherung erfordern. Ist der Bedarf größer,
wird das Fenster nicht geöffnet! Der maximale Speicherbedarf bei
Karten bis VGA und bis 480*640 Pixel bei 16 Farben beträgt:
(X1-X0+3)*(Y1-Y0+3)*80 Bytes, so daß bei diesen Karten ein einzelnes
Fenster höchstens ca. 1/3 des Bildschirmes überdecken darf.
******************************
* CLOSE_WINDOW (N : integer) *
******************************
Schließt ein zuvor geöffnetes Fenster wieder. Die unter dem Fenster liegende
Bildschirminformation wird dabei restauriert. Mit N muß der Prozedur die
von OPEN_WINDOW zurückgelieferte Nummer übergeben werden.
***********************************************
* WPRINT (N,X,Y,COLOR : integer ; S : string) *
***********************************************
Gibt den Text im String S im Fenster mit der Nummer N aus. Der Text wird an
den Positionen X und Y ausgegeben. Diese Koordinaten beziehen sich auf den
Ursprung des Fensters und nicht etwa auf den des Bildschirmes. Somit ist
bei einer späteren Verschiebung des Fensters keine Änderung der Ausgabe-
befehle erforderlich. COLOR definiert die Farbe des Textes. Dieser muß in
das Fenster "passen", sonst wird er nicht ausgegeben.
*****************************************************
* WINPUT (N,X,Y,COLOR : integer ; var OUTS: string) *
*****************************************************
Ermöglicht dem User im Fenster mit der Nummer N an den Positionen X und Y
die Eingabe eines Textstringes. Der Textstring wird in der Farbe COLOR im
Fenster dargestellt und in der Variablen OUTS an die aufrufende Prozedur
übergeben. Auch Zahlen werden in einem String zurückgegeben.
******************************
* CLEAR_WINDOW (N : integer) *
******************************
Löscht den Inhalt des Fensters mit der Nummer N vollständig. Das Fenster wird
also mit seiner definierten Hintergrundfarbe überschrieben.
***************************
* WREVERT (N,Y : integer) *
***************************
Invertiert im Fenster mit der Nummer N den Y. Eintrag in diesem Fenster auf
voller Länge. Ein erneuter Aufruf der Funktion mit den gleichen Parametern
stellt den ursprünglichen Zustand wieder her.
************************************************************************
* WINDOW_STAT (N : integer ; var Y,B : integer ; var SCAN_CHAR : char) *
************************************************************************
Erteilt der aufrufenden Prozedur Informationen über das Fenster mit der
Nummer N. In Y wird mitgeteilt, über welchem Eintrag des Fensters sich der
Mauszeiger befindet und B spiegelt den Status der Mausknöpfe im üblichen
Format wieder. Damit dieser Vorgang auch ohne Maus über die Tastatur
funktioniert, muß wie bei den anderen Libraries in SCAN_CHAR der 2. Wert
des erweiterten Tastaturcodes oder CHR(13) übergeben werden.
Das waren die öffentlichen Prozeduren der WINLIB.
Zusätzlich verfügt auch die Winlib über eine CLR-Prozedur zum partiellen
Löschen des Grafikbildschirmes. Diese Prozedur ist darüber hinaus ohne jede
Bedeutung.
*****************************************************************************
Veränderungen und Erweiterungen ab V4.0
*****************************************************************************
Zur Version 4.0
---------------
Am MBM-Paket selbst wurde (fast) nichts geändert: Daß der Mauszeiger nicht
ganz sauber ist (oberer Teil der AND-Maske falsch definiert) gehört nun der
Vergangenheit an.
Wesentlicher ist die komplette Eingliederung der Sprite-Library V1.2 in das
MBM-Paket. Diese Pascal-Routinen sind eigentlich weniger für schnellbewegte
Sprites, als vielmehr für das Konstruieren und Anzeigen von Images von
Bedeutung. Alles weitere entnehmen Sie bitte der Beschreibung für die
Sprite-Library selbst.
Da sich DRV_Link durchgesetzt hat, wurde ab der Version 4.0 vollständig auf
die Beigabe der BGI-Treiber verzichtet. Wer Sie dennoch benutzen möchte,
findet Sie auf den originalen Pascal-Disketten.
Zur Version 4.1
---------------
Wesentlichster Grund für die Erstellung einer neuen Version war die Not-
wendigkeit, meine neue Adresse in das Programm einzubauen. Damit jedoch
auch ein echter Nutzen für den Anwender dabei herausspringt, wurde das
Programm-Paket dabei gleich noch ein wenig ausgebaut.
Die Winlib erhielt dabei eine neue Prozedur, die es dem Programmierer
ermöglicht, dem Anwender schnell eine Mitteilung in einem Fenster zu
übermitteln. Dazu muß nicht erst groß ein Fenster geöffnet und mit
WPrint-Anweisungen beschrieben werden. Es geht viel einfacher:
**********************************************
* INFO_WINDOW (C : char ; S1,S2,S3 : string) *
**********************************************
Die Nummer des Windows ermittelt die Prozedur selbst. Das Fenster wird
automatisch zentriert. Das Zeichen in C wird in der linken oberen Ecke des
Fensters besonders hervorgehoben (z.B. ein "!" oder ein "?").
S1, S2 und S3 sind drei Strings von maximal je 30 Zeichen Länge, die im
Fenster untereinander dargestellt werden.
Der Anwender kann das Fenster durch Druck auf den "OK"-Button wieder
schließen. Sie als Programmierer müssen sich dabei um nichts kümmern.
Die Prozedur meldet sich erst nach der Quittierung durch den Anwender
und dem automatischen Schließen des Info-Fensters in Ihrem Programm zurück.
----------------------------------------------------------------------------
Mit dem MBM-Paket V4.1 verfügen Sie über etliche Prozeduren, die die
Erstellung von Programmen in Pascal für den Grafikmodus wesentlich
erleichtern. Viel Spaß dabei.
*****************************************************************************
*****************************************************************************
Hier kommen nun noch alle möglichen Fehlercodes:
Error bei bei bei
Nummer MOUSEERROR BUTTONERROR MENUERROR Beschreibung
0 ja ja ja kein Fehler
-1 ja ja ja kein Grafikmodus aktiviert
-2 ja ja ja kein Maustreiber installiert
-3 ja ja ja unerlaubte Koordinatenangaben
-4 nein ja nein unerlaubte Ebenen-Nr. angegeben
-5 nein ja nein unerlaubte Button-Nr. angegeben
-6 nein ja nein doppelte Button-Deklaration
-7 nein ja nein keine aktuelle Ebene ausgewählt
-8 nein nein ja unerlaubte Menü (X/Y) Position
-9 nein nein ja Menüeintrag ist zu lang
-10 nein nein ja Menü ist nicht eingeschaltet
-11 nein nein ja kein Menüeintrag ist vorhanden
-12 nein nein ja unerlaubter Markierungswert
-13 nein nein ja kein Menü ist heruntergeklappt
-14 nein nein ja unerlaubter Revertmodus
-15 nein nein ja nur nach MENUPULL: kein Speicher
Die Fehlercodes der WINLIB:
windowerror Bedeutung
0 kein Fehler
-1 ungültige Koordinaten
-2 alle Fenster belegt (=> 10 Fenster offen)
-3 kein Speicher (Fenster zu groß oder Heap voll)
-4 unzulässiger Farbcode
-5 unerlaubte Windownummer (wurde nicht vergeben)
-6 Window ist nicht offen
Hier endet die Beschreibung der 30 öffentlichen und der 4 nicht-öffentlichen
Prozeduren der 4 Units MOUSELIB/BUTLIB/MENULIB/WINLIB des MBM-PAKETES V 4.1
Das wars - ich hoffe nicht zu ausführlich und nicht zu knapp.
Und nun noch: Viel Erfolg.